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A. THE PROBLEM 

Recent literature is replete with dire predictions about 
the ultimate costs orf software maintenance. EReig7s.) COStS 
of software in the United States were $20 billicn [{1] and 
they are projected to be $200 biliion in 1985 {21. It has 
D2en hypothesized that anywhere from forty tc ninety-five 
percent of the manpower effort in typical industrial appli- 
cations occurs during the maintenance phase cf the scftware 
fopsewcycic.s. 9 (3, 4, 54 5, Ty 8, Ge 10, 11, 12, 13, 14] 

Although there are numerous modelS in existence that 
deal with software costs, none deal specifically with the 
costs of ‘pure maintenance during the latter phase of the 
software life-cycle. It appears that much of the Federal 
Government and industry tend to use a general definition of 
software? maintenance and treat it as alevel of effort on 
various tasks rather than thaz erfort allocated to specific 
asks. Consequently, these organizations do not really 
Know the true ccests cf thelr software maintenance. 

The goal of this work is to investigate the methodology 
of software cost accounting, and to evaluate and deveiop a 
cost model for the prediction of pure software maintenance 


SOStS. 





De BACKGROUND 

The term ‘'Software Maintenance’ is very nebulous. De- 
partment of Defense Directive 5000.29 alludes to software 
maintenance by stating: 


Seemeeceness Of SOftwarée, reliability, integrity, main- 
Poeeaowetty, ease of modification, and transferability 
+c be major considerations in the initial design. 


Used in this thesis is a composite definition of software 
maintenance to encompass those actions taken bya systen 
Weeotecemae ain an Existing system in, cr restore it to, an 
operable condition. This includes: 

1) corrections to counteract detected bkugs; 

2) enhancements to add functions; 


Peete cactons to delete or Change existing functions in 
their nature or scope; 


4) implementaticn 


pis SEES oy tO Match changed conditions or 
requirements. {16, i/, 18, 


or e20Ge 2iga clay coy 24} 
‘Pure! Maintenance on the other hand is restricted to 

that work accomplished during the maintenance phase of the 

SQimtwcane lore cycle in the pursuit ot the following goals: 


ieee newt ey Or Software - the ability of the software 
to produce consistent results whenever the customer 
uses the preduct; 


PimonuemmCOGEec 10h ==> Changes made to counteract errors. 
MWewPSlOrity Of CCEFEeCction is directly related to the 
seriousness of the error; 


Soo Gewat- Maintdainabidity - extending the useful life of 
@ proqram by untangling a@ messy one, generalizing a 
specific one, cr annotating an unreadable one. 
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Robert Glass [25] defines the best software maintenance 
aS no maintenance at all. That is, no changes are needed be- 
cause no errors were committed and all changes were antici- 
pated. He then goes on to list six attributes of software 
maintenance: 


1) Maintenance is intellectually Dee difficult. Problems 
cannot be bounded. The cause cculd Le anywhere. 


2yeMazhntenance is technically very difficult. Problems 
cannot be specialized. They could surface because of 
Seeero en the coding, GeSsign, architecture, cr concept. 


3) Maintenance is unfair. Usually the person who is main- 


Meermang a PLOdUucCt did not write it and must interpret 
what the original author meant. Documentation is in- 
adequate most of the time. 


4) Maintenance is ne-win. People only come to maintenance 
with problems. 


5) Waintenance is infamous. Bichomels Velyelattle glory, 
noticeable progress, or chance for ‘success’. 


6) Maintenance lives in the past. The general quality of 
code being maintained is often terribie. This 1s part- 
ly becausé it was created when everybody's understand- 
ing of software was mcre rudimentary and partiy be- 
cause a great deal of code is produced by people before 
they become really geod at programming. 


Researchers dc not appear to be using the same defini- 
“ion when working on the costs of maintenance. Those who es- 
‘imate maintenance costs to be near forty percent of life- 
cycle costs seem to be using a definition closer to that of 
'puret maintenance while those who estimate maintenance as 


Negaeasweninety-five cercent are obviously using a very 
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@emesalead2finiticn. AGeeraing to recent surveys, most 
(seventy +t0 eighty-eight percent) Maintenance effort is 
spent modifying software to accomodate changes and to in- 
prove software performance rather than to correct errors 
which were not discovered during systems development. { 26, 
27, 28) These surveys have been substantiated by analyses 
done on three iarge scale systems: 


gieaciiic Telephone = Service Order Retrieval and Distri- 
bution System; 


2) Bell Telephone Laboratories - Automated Repair Service 
Bureau Syste; 


3) VISA, Inc. - Base II World Wide Credit Card Transaction 
Interchange System. [29] 


Aithough hardware costs have decreased by over two 
orders of magnitude and programmer productivity has in- 
creased by one order of magnitude in the last ten years, the 
total costs c& systems are continuing to rise with the 
greatest portion of effort and cost spent after development 
GCempletion [30]. There appear to de four primary reasons 
for this phenomencn: 

1) Maintenance is people intensive; 
2) The number ct systems has increased substantially; 
3) The mission of the software seems to be expanding; 


4) age system lire has increased from three years in 


Aver 
1960 +o ive years in 1970 to eight years in 1980. 
pou se | 


Ree 





A cvecent DOD study reports that development costs for 
Alix Force avionics software averaged $75 per instruction 
while maintenance costs lie in the range of $4,000 per in- 
struction {33] This indicates that ninety-eight percent of 
the life-cycle costs of that system are spent cn software 
maintenance. Ancther study concludes that fifty vercent of 
=he costs for Navy Airborne Antisubmarine Warfare Tactical 
Software is spent on maintenance software [ 34]. As one can 
see, there are many different meanings or the term ‘software 
maintenance! and as many different assessments of its cost. 

The software industr aqoes not appear to be unified in 
its approach +o decreasing the high ccst of maintenance. 
McClure states: 


"A solution that focuses upcn the production phases of the 
software life cycle does not address the major portion of 
the maintenance e¢ffort... We must directly address 
maintenance issues rather than hope that they #iil disap- 
pear by pene? and the development process." { 35] 


Most of tae ieee ccure expounds the theory that, to be done 
properly, software maintenance should be a conscious goal 
from the beginning cf the software development process. 
Maintenance is all too often left out cf planning considera- 
sions and then treated as a helter-skelter, uncoordinated 
activity rather than a planned, methodical, controlied nec- 


essary business function [ 36}. Long term planning, just as 
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in cther disciplines, includes the provision of appropriate 
tools. There are two major eG ore es cf tcols for maiate- 
nance. Technical tools encompass such things as compilers, 
traps and traces, dumps, ccmparators, editors, reformatters, 
and preprocessors. Administrative tools include problem re- 
porting vehicles, status reporting vehicles, and documenta- 
tion systems. (37, 38, 39] 

Even with the knowledge and use of these tools, produc- 
tivity, which is typically measured in software lines of 
code ({SLOC) is substantially lower for maintenance prograna- 
mers than fer development rrogrammers. ACCOr ding 20 Daly, 
Maintenance productivity can be as low as twenty percent of 
development productivity [40]. There appear to be three 
Main reasons fer this phencmenon: 


1} There is a stigma attached to the job of software 
maintenance. Management rarely rewards good work in 
aoe g Maintenance aS generously as good work in doin 
development. Both coworkers and management personne 
act as though they held maintenance work in low esteen. 
Eeeslevave, C¥yery person must have self respect. iia 
Fob 1s not ercélived aS important, a person probably 
aoeeenot perromm to the best of his abilities. 


2) Usually, . maintenance personnel @5e (00t Gneitacelyeca— 

Miliab wil=h the ¢cde that they are assiqned to nain- 
Fen. Beas a maintainer is assigned responsipil- 
ley fOr OFC OeSL OG | i 4 1). Because documentation is 
guite often poor, the Maintainer must Study the code 
itself and try to understand what the original develcop- 
ar created and i he implemented it in chat manner. 
Usuaily he nust s a a great deal more code than the 
affected area to avold inducing bugs in a seemingly un- 


related area by the fix that 1s implemented. 


3) The wrong grade of people are typically used to staff 
maintenance efforts [42, 43, 44, 45, 46, 47, 48, 49] 
PaaieesOonmal iy, malntenance Ssfforts are déing starred oy 
less €xperienced overscnnel than development projects. 
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However, maintenance personel should tbe senior peopie 
because scftware maintenance 1s a microcosm of the en- 
tire software development process. The maintainer does 
a systems analysis of a problem area leading to a te- 
quirements definition. Donning a designer's hat the 
Matntenance person then outlines the impact of the 
change on .*he product. Beard a flexible individual, 
the Maintainer now codes the design solution. After 
the results of these efforts have been tested and veri- 
Fi2d the revised product is finally released to tne 
world... The maintenance person also ane a liaison 
role with the customer by explaining anomalous outputs, 
negotiating changes that are needed as eupesse to those 
that are desired, and interpreting the computer's 
unique constraints. AS you Can Sec, the _person wno 
Maintains a complex system should bea highly talented 
am @OtaYated g@ndividual. [50, 351, 52] 


C. RESEARCH METHCDOLCGY 
1. Literature Search 
Manual searches and automated system searches of the 
literature showed little had been published in this field. 
Although there is a4 lack of published material that deals 
Peeeectivyewitne a fiscal approach to plaaning and control of 
software maintenance, the researchers found a great deal 
that was very useful as background information and which 
helped ¢ develop the theory for the planning and control 
model. 
2. Telephcne Cenversations 
Efforts to uncover informal sources that deal spe- 
eaeeeGatiy with the costs of "pure maintenance’ failed. The 
rollowing organizations were contacted in the course of tne 
research, with no significant results: 
Army Computer Systems Command, Ft. Belvoir, Va.; 


DOD Computer Institute, Washington, D.C.; 
13 





PEDSIOS Washington, 0.C.; 

Homestead Software Support Facility, Homestead, Fl.:; 
ISM Federal systems Division, Gathersburg, Md.; 

Kapur Associates, Danville, Ca.; 

National Security Agency, T303, Ft. Meade, Md.; 

Wavyal Securssy Group Activity, Skaggs Island, Ca.; and 
NARDAC San Franciscc, Alameda, Ca. 

Maintenance tracking data, dealing with Goddard 
Space Flight Center projects, was obtained from the Data and 
Analysis Center for Software, Griffis AFB, NY. Unfortunate- 
ly, the Late arrival of the data and f£crmat incompatibilit 
precluded inclusicn of this data. 

Unpublished documents describing a matrix management 
nethod of functicnal area analysis developed by Mr. Kyle 
rone, IBM Federal Systems mVvVeswone — TOUStON, 1X. were 
obtained and significantly contributed to the formulation of 


*he final model. 


WeeeOaGaiei ZATION OCF THE THESIS 

ip «his introduction tke propiem has been stated, its 
-mpor<zance discussed, and it has been piaced in the context 
of the overali computer system development process. Chapter 


=wo covers various aspects cof the problems enccuntered when 
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astimating/sdeter@ining the cost of software maintenance. 
This specific backgrcund material is needed to understand 
the models that will be presented in chapters three and 
four. Chanter three thoroughly discusses existing rodels in 
“wo areas: those that work with Norden-Rayleigh curves, and 
those that encompass complexity metrics. Chapter four gives 
the authors! nodéel which 1s based on both macrco-estimating 
(eoceal sys-em) and Micro-estimating (unit composition) tech- 
nigues. Finally, chapter five summarizes the thesis and 


puts forth, conclusions and recommendations. 
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- PCUANTIFITNG SOFTWARE MAINTENANCE 


A. THE SOFTWARE EROBLEM 
There are two main reasons that maincenance has become a 
predominant cost in software systems. First, the volume of 


completed systems which require maintenance dominates the 


(n 


ystems under development as more and more long-lived large 
systems are completed and délivered. Second, software sys- 
tems require a ccnsiderably greater proportional investment 
in error correction and evelutionary maintenance after de- 
livery than other engineering products. 

Numerous technological advances have not solved software 
problems. They have increased the demand for software, and 
opened up cpportunities to usé computers in new applications 
which place increasingly severe demands on software tech- 
nology. Often the tendency is simply to ignore these prob- 
lems. Because these problems are Doth technical and aana-~ 
g2rial in their scope, a "systems engineering” solution is 
needed. 

Unliks hardware operation and support models, where the 
cost of spares, maintenance manhours, material, training, 
etc., can be estimated based on some physical characteris- 


SG -wO=mone system, =SOLtWwars maintenance effort 15 stricti;y 
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a function of manhours to perform the necessary action. 
Thus far, maintenance costs for software seem to be primari- 
ly an estimate by an expert, someone familiar with the 
Changes to be made to a program, rather than putting certain 
parameters into a cost estimating relation and caiculating 
annual maintenance costs. 

Software maintenance costs cannot be ascribed to one 
specific agent or event but instead to the combined action 
of many factors. By reviewing some of these, the complexity 
of the problem can be better understood. In this research, 
an attempt is madé tc isolate areas that can be estimated by 
formulas and then to establish the mathematical relation- 
ships. As such, the following topics will be discussed as 
*hey relate to the maintenance function: 

1) Software Life-cycle; 

2) Life-cycle Interrelaticnships; 
3) Software Evclution; 

4) Productivity; 

DieeGompLlexizy Metrics; and 


6) Error Frediction. 
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Pests coOr avant LIFE-CYCLE 

In the mid 1970's, the phrase "Softwara life-cycle" was 
coined and became a popular means for conveying the basic 
concepts of a software system: muatiple phases and extended 
life. Many representations of the life-cycle exist; by con- 
monly accerted practice, the software life-cycle consists of 
the development phase and the maintenance phase taken col- 
meectively. Depicted in Figure 2.1 is a composite schematic 
showing this relationship. 

This diagram oversimplifies the importance of the 
Maintenance phase. A more accurate role of the maintenance 
function is detailed in the life cycle model (figure 2.2) 
developed by Rome Air Development Center [53]. Paguucoals 
view, maintenance performed during the operation and support 
phase is seen to bre a highly interactive process. The con- 
jecture apparent from the diagram is that the same procedur- 
al requirements fcr software develcpment must be duplicated 
during the maintenance chase. 

The basis of applying a life-cycié management scheme <*o 
software is to direct attention to all phasesS encompassed Dy 
“he system life-cycle and the contribution cf each phase to 


she total life-cycle expenditures. Pc Meee i tts With and 
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understanding of the life-cycle can help managers make ef- 
fective distribution of the resources for a software systen 
which will ultimately affect the maintainability of the 
software. 

The life-cycle curves, more recently called "Rayleigh" 
curves, were orginally formulated by Lord Rayleigh, the 
British Nobel Laureate. Presently, these curves are used to 
represent resource allocation (manpower) of a software pro- 
ject. Preliminary research in this area was directed at re- 
source consumpticn in research and development (R&D) pro- 
jects. In a series of studies conducted by Peter Norden 
[54] of IBM, it was established from a large body of empiri- 
Gal evidence that large R&D projects follow a life-cycle 


pattern as described by the Rayleigh (manpower) eguation: 


2 
= aac 
y' = 2Kate (20) 
where 
y' = the number of person-years oz effort expended 
per year, 
K = the total number of person-years required over 
the iite-cycle, 
a = the curve shape parameter, 
t = elapsed time in years, and 


iD 
il 


axpcnential function. 
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TNeeenanearple Of the Curve is as follows: Research has 
indicated that there are regular patterns of manpower build- 
up and ohase~out in complex projects. These patterns are 
made up of a smali number of successive phases or cycles of 
work thoroughout the life cf the project. Norden linked the 
cycles to obtain a project profile. When the individual 
cycles are added together, they produce the profile of the 


mete pEOjyec= (figure 2.3). 
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Figure 2.3. Project Profiie 


peak manloading time ot culainates during final stages 


development and implementation (figure 2.4). Based upon 


th 
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Figure 2.4. Manloading Profile 


Norden's studies [55], cumulative resource allocation up to 
this time acccunts fcr approximately forty percent of the 
life-cycle. Occuring at the low end of the curve is the op- 
eration and maintenance phase which absorbs the remaining 
Sixty percent of life-cycle expenditures. The greater por- 
*ion of costs associated with this phase are attributed to 
she “gaintenance tail" cr expected life cf the software pro- 
tee Failure repair, however, is just a small part of 
post-delivery maintenance activities. Studies [56] show 
Setrmecoming C==crs acecunt for only thirty percent of the 
post-delivery errors. The greater snare (seventy percent) is 
occasioned because there is a mistake in design cr specifi- 
cation. Although the cede performs exactly as designed, this 
does not reflect the original operationai desires. 
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wogacally, it would seem that maintenance manpower 
requirements weuld decrease over time due to growth in reli- 
ability. In other words, as programming and design errors, 
which are commonly called "bugs", are found and corrected, 
the time to the next system failure should increase through- 
out the maintenance phase of the life-cycle. This reliabil- 
ity assumption, however, is disputable. Maintenance action 
taken in response to error cccurance can have three possible 
outcomes: 


1) the actual error is corrected; 


2) the error is corrected, but the fix lnducées a new 
SmrOrL 5 
Syeeeie = CLOL is not corrected, and the program remains 


non-operational. 
Reliability growth, then, is a probabilistic event which de- 
pends heavily on the skills of the maintenance programmers. 
Tf the maintainers are competent, reliability should grow. 

Another contreversial assumption iS growth in maintain- 
aod arty . When maintainability 1s viewed as tne time re- 
quired *o return a software system to an operating status 
following a system failure and maintainability growth is 
viewed as the decrease in time reguired to correct an error, 
then an obvious conclusicn would be growth in maintainabdil- 


ees Several factors, hcwsever, may produce an opposing 


ae 





Senmclus2on, 1.¢€. decaying maintainability. Patchwork fixes, 
in addition to introducing new errors, may produce nodule 
interface problems and documentation inefficiencies will 
complicate the finding of cther errors. Reduced familiarity 
with a software systen, stemming from frequent personnel 
eemover, can be an inhibitor. Documentation and software 
(programming) standards and controis may not be enforced on 
new releases. Errer identification and correction may be- 
come further entangled when configuration control is lax. 
Again, the competence of the maintainers will infiuence the 


resules. 


Gyeeeour s-CYCLE INTERRELATIONSHIPS 

The management process for the maintenance of software 
involves déecisiors in establishing control of changes to the 
software and in providing for the implementation cf iaproved 
mimeeconal Cababllity throughout the life-cycle of the soft- 
ware. The planning to acquire and implement resources for 
software maintenance must: 

ieeote.ce> =h= entire life of the software, and 


2) early in the life of the software in order to 


begin 
Besepvennunding and identity sufficient resources for 
the future. 
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PeemerencettMe Spans and levels of effort exist for the 
different phases of a software project. The failure to ob- 
tain quantitative relationships of a precision comparable 
to those available for estimating the costs of hardware sys- 
tems has led to the belief that interrelationships exist 
among life-cycle phases. That is, the amount of resources 
used in early phases impacts heavily cn the resource re- 
quirements for later phases. Using an approach similiar to 
basic 2ccnomic froduction theory, Thibodeau and Dodson [57] 
developed a mathematical mcdel to descrire the complexity of 
the phase interrelations. This relationship is given in the 
LOrm: 

Q = AK L (222) 
where 

Q = the level cf output, 

K = the amount of capital irput, 

L = the amount of labor, and 


A, a, and b are empirically derived constants. 


rth 


eeaprecatiy, chas is shown in figure 2.5. 
To add a term representing technological change or to 


account for different classes of lakor or capital, the nua- 


ber of input rescurces can be expanded to 


Q = AK K_oL (2. 3) 
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Meare goo6 ECOnemac Production Curve 
In order to indicate trade-offs between life-cycle phasés, 


“he same general formulation can be used and expressed as 


bescua ») Kk 
P= oe Mek ok (2.4) 


where 

P = software production resulting from the applica- 
tion of the resources, 

X = person-months of inputs, 
a, ob, c, da, and k are empirically derived con- 
stants, and 
Sibscete.s d, CG, £, M Lepresent designina, coding, 
testing, and maintenance respectively. 

A further asserticn made by Thibodeau and Dodman indi- 


cated that limitations in design resources (€.g. a reduction 





in planned resources) may be passed through the development 
phases with final impact in the maintenance phase (higher 
error rates). Based on the mathematical postulate previous- 
ly described, this type of relationship can be shown by the 


@caph in figure 2.6. 
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Pagure 256. Application of Production Theory 


Memoeseceiping the infinite set cf relationshics, table Tf 
itilustrates some departures from the ideal which may occur, 
and how 2 reduction or increase of resources in these phases 
will ce reflected in the error rate of the delivered soft- 
ware. While it can be argued taat the ideal error rate nay 
PemzerOo, a MOLDS practical solution would te to avoid de- 
dicating an e¢ncrmous amount of resources to achieve zero 


errors. As a result, it wouid be expected that for most 


Cu 
Lu 





information systems, planning would aliow for some marginal 
error tate. However, this tolerance of errors does not nec- 


essarily apply to tactical defense systems. 


De SOFTWARE EVOLUTICN 

Operational software systems undergo a continuing pro- 
cess of evolution, the phases of which are repair, nodifica- 
tion, enchancement, and adaptation. Continuing evolution is 
the visible sign of continuing interaction between the sys- 
*em and its environment. LVc iat —anG ptUnis ee rare! y , wale 
ever, occurs-- its first implementation was perfectly con- 
ceived, perfectly designed, and perfectly implemented, a 
program will require genéerai maintenance. 

Evoluticn dynamics is a theory describing the change of 
a software system over a period of time. The theory distin- 
guishes between progressive work (to introduce new features) 


and antigressive work (fault correction, testing activity, 
and investment in methodology to combat the complexity which 
grows with system size) { 58]. The basic assumption of pro- 
gramming evolution dynamics is that it is legitimate and 
necessary to view a large program and its maintenance orga- 


Meeeteon as interacting systems. Thus one must search "for 


models that represent laws that govern the dynamic behavior 
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or the metasystem of organization, people, and program aa- 
serial involved in the creation and maintenance process" 
P59, 60]. 

Feedback is tasic to the process since the system and 
System designers are considered as a metasystem. The key to 
good feedback is intensive use over time. The more the 
software is used, the better it gets, as long as deficien- 
cies are fed back into the maintenance group and corrections 
are made. This statement holds true provided that the nain- 
tainers introduce fewer errors than they resolve. Likewise, 
the longer it is used the less the probability that the sys- 
“em contains major deficiencies. In analyzing a software 
developmen* system, a simple beginning would be as shown in 
mreaure 2.7 . When pressure is exerted tc provide bigger re- 
leases (later versions of a system that contain enhancements 
and/or corrections), ‘the results are more complexity, fre- 
duced quality, and growth rate limiting factors. Eventuai- 
ly, releases are made solely for restructuring/rewriting. 
At this point, a fission effect is pessibl2 where excessive 
growth leads to system breakup. 

Various published papers [61, 62] have discussed the 


characteristics and dynamics of the evolution of large 
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Figure 2.7. Development Release Cycle 


programs, with the most significant contribution cf research 
done by Lehman and Belady {63, 64]. Their efforts were di- 
rected at understanding the dynamics of the software life- 
cycle, thereby creating an enhanced environment of manageri- 
al awareness and an understanding cf system behavior. Long 
term unpredictability of the system development and mainte- 


nance processes have been attributed to the human interface. 


Mm 


However, it has been found that measures of System activity 
such as number of modules handled, inter-release tine, and 


total number cf modules in the system, show an unusual 
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Megularity. Since this regularity could not be attributed 
tO management d¢cisions, Lehman and Belady have tried to 
analyze it through the use of evolution dynamics. By de- 
scribing the environment of program creation and maintenance 
in terms of regularities, trends, and patterns, they have 
proposed laws governing the evolution dynamics (tabie II). 
Features of these evolutionary trends were further sup- 
ported in a more recent study by Leintz and Swanson LoS}. 
Analysis of data obtained from an extensive survey indicated 
that the magnitude of a maintenance effort can be explained 
by the combined efforts of four variables: system age, sys- 
tem size, relative amcunt cf routine debugging, and the re- 
lative experience of the maintainers. The relationships of 
these variables were modeled as shown in figure 2.8. Amount 
of maintenance effort, the dependent variable, 1S seen to be 
influenced through five other causal paths involving four 
variables. Each causaél path is initiated from the indepen- 


dent variable, system age. 


ta 


Mee ecovpUCTIVITY 
Productivity is often considered a measure of the trans- 
formation of meaningful and controllable units of input to 


meaningful and controllable units of output. The guestion of 
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TABLE I1 


Laws of Evolution Dynamics 


— a ee, ee ee ee ee ee ee a aa mm ae ae ee Sa Ga oe es ee eee nee ee 


CONTINUING CHANGE 


A program that is used and that, as an implementation 
Sige specification, ~Ceflects some other reality, 
undergoes Somes Change or becomes progressively 
less useful. The change or decay process “continues 
until it is judged more cost effective to replace the 
program with a recreated version. 


INCREASING COMFLEXITY 


As an evolving oa ls continucusly changed, its 
complexity rer ecting deteriorating sturcture, in- 
creases unless WELK L=saone tO MA€intain Or Lreduce it. 


THE FUNDAMENTAL LAW®@ 
(OF PROGRAM EVOLUTION) 
Program evclution is subject to a dynamics which 
makes the programming process, and hence measures of 


global project and system attributes, self-regulating 
With statistically determinable trendsS/invariances. 


cme cy SR GUI ee SR ee i i ts Se ee, Se SE Ce, Se ce ee ee ee cenreeen con ame 
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CONSERVATION OF ORGANIZATION STABILITY 
(INVARIANT WCRK KATED) 
Piemgrebal ectivity rate in a eC eos supporting an 
evolving prcgram is statistically invariant. 
CONSERVATION OF FAMILIARITY 
(PERCEIVED COMPLEXITY) 
The release content (changes, additions, deletions) 
of the successive releases of an evolving program is 
Seawmestically invariant. 


_ ae ae ee a OP a ae ae Se > a ae ap oo ae ee ee ee ee a ee ee eee Se Se ee 


quality must be understood in all measures of productivity, 
if they are to have méaning. It 1S tar easier to be more 
productive when producing throwaway products than it is when 


producing high quality output. 
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Pigure 2.8. Casual Paths of Maintenance Effort 


i= software is sized in terms of a product measure such 
as the number of instxructicas or modules, then the assumed 
personnel productivity against those measures is a key vari- 
ant in the estimate. Since producing software is a very 
labor intensive activity, consuming greater than eighty five 
percent of the resources aiiccated for software development 
(66j, an *sséntial ingredient for arriving at an accurate 


of the software lies in personnel froductivi- 


iP 


cost estimat 
eee Generation cf software is creative and, thererore, a 
wide variance across perscennel productivity can be expected. 
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Budget estimations required fer software development 
have led to an abundance of research exploring the topic of 
programming productivity [67, 68, 69] Traditional measures 
of software productivity have included: 

Hye eadollars per defect, 

2) lines of code (LOC) per person-month (PM), 
BljeweeoLttars per LOC, 

4) dollars per PM, and 

5) complexity fEranch per 1000 LOC. 

Maintenance researchers pose the yet unanswered ques- 
2 On > Can the same criteria be applied for productivity 
during the maintenance phase? Within a maintenance scenar- 
io, module constituents cf a software application can be 
categorized as new, modified, retained, and converted (fig- 
ure 2.9). New segments consist of entirely new code. Modi- 
fied segments areé composed of changed code and the unchanged 
code that mav be affected by the changed code. Retained 
code consists of previously developed and tested segments 
that will be integrated into the scftware products without 
being modified. Converted code is existing code converted 
=O ancther language. Each of the categories of code, wnoen 
related cto a specific product, may produce a unigue produc- 


Pavey Pate . 
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Figure 2.9. Categories of Program code 


Factors which influence productivity have been widely 
researched. Data collected from sixty projects by Walston 
and Felix showed that Significant relationships existed 
petween productivity (SLOC) andthe ratio of developed code 
ro the sum of original (or reused) code plus the developed 
Soageewtvuy. The resulting plot shown in figure 2.10 suggests 
that productivity is highest when there is no criginal or 
reused code, that is, when all the ccde is developed fron 
PomeneaotzOon Of the project. As the percentage oz reused 


code grows, the expected preductivity decreases. 
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Figure 2.10. Productivity - Reused Code Relationship 


Recent investigations done by Swanson and Leintz, re- 
vealed that while productivity techniques have been exten- 
Sively discussed, few systemic studies of benefits in tae 
maintenance phase have been conducted {71]. Figure 2.11 
—memwmea scene, Dut not all, c£ the g£factcrs cecmmonly cited as 
mieatees, Of Productivity. 

Maintenance costs must be viewed collectively with pro- 


fiery "O .ac less 1S to tocus on only part of the 
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Figure 2.11. Preductivity Determinants 


issue. It could be a misleading focus if management dic- 
*aztes oolicies that result in high productivity during de- 
velopment work kut adversely affect the productivity of 
post-delivery maintenance. If the productivity 1s negative- 


ly affected because cf internal problems prior to delivery 
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or reduced guality when in use, tnen costs will increase and 


meeect =ne potential <o complete other projects. 


BomecOne Lok ily “METRICS 

Quantitative metrics which assess the complexity of 
software continue to attract a high degree of interest. 
Thes® metrics aré assumed to be vaiuable aids in determining 
the quality of scftware. A collection of such metrics which 
assess numerous factors that constitute this nebulous "soft- 
ware quality" have been proposed [7Z, 73]. Such factors in- 
Sumas celiability, portability, maintainability, and myriad 
other xxx-abilitiées. 

Potential uses for measures which assess these various 
factors are manifold. Importance of metric relationships 
lies in the follcwing areas: 


Mieseececdvack to programmers, they can be used during de- 
velopment to indicate potential Pt car with developed 
code [74]. A design is evaluated with the metric rela- 
Cretmsniwps in Wand. T£ it appears that this design falls 
outside of the metric bounds, then another design mtust 
be contemplated. 


2) In guiding software testing, McCabe's cyclomatic number 
has been preposed as a means of assessing the computa- 
tional complexity or the software testing problem [75}. 
Other metrics which index the ee tty cr complexity of 
SOtewate May hele identify modules or subroutines which 
are Likely to be most error-infested. 


Byeetemene Of a Combination of metrics can pe empirically 
related to the difficulty programmers experience, then 
More accurate estimation can be, made of che manpower 
that will be necessary during maintenance. 
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iemedeeang =~hese metrics, it is important to distinguish 
between the computational and psychological complexity of 
software, since reasons for assessing them differ. Computa- 
solutions to computational problems" [76] such as comparing 
the efficiency of alternate algorithmic solutions. TO 
Infstrace, as the number of distinct control paths through a 
program increases, the computational complexity may in- 
crease. Psychological complexity refers to characteristics 
of software which make it difficult to understand and work 
with. Psychological complexity can then be thought of as 
assessing human performance on programming tasks. Subse- 
quent sections will discuss currently used metrics that aave 
been coupled with the maintenance effort in an attempt to 


predict programmer effort required to complete a specific 


Maintenance task. 


hia 
lie 


During the last few years research aimed at the de- 
7elopment of a “software science" has supported the conten- 
+ion that ‘there may be simple theoretical explanation for 
she structural characteristics of many computer programs aad 


=hat there is a strong guantitative relationship between 
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mmese Cidlacteristics and the effort required to write pro- 
feos f//, 78, 79]. Based on the thecry of software sci- 
ence, five entities of an algorithm expressed in a ianguage 


are measureable: 


nN 


number of distinct operators, 
1 


5 = number of distinct operands, 

i. = total number of operators, 

an = +otal number of operands, and 

tp = number of input/output parameters for the 


algorithm. 
From these measurements, some defined properties for pro- 
grams can be calculated: length (N), vocabulary (n), voiume 
(VY), and program level (L). [80] 

Using the simple relationships Letween these metrics 
and the effort (EF) required by a programmer, Halstead ar- 
Tived at an expression of effort (total number of elementary 
mental discriminaticns) +o generate a given program where 
n HAM + i ods ae vere) 


5 a ice ee a ae ee (2.5) 


K) 


By applying the Stroud number, which is the number 
of elementry pieces of data that a perscn can mentally sep- 


2ratea per second (S), a dimension or time is introduced to 
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E V 
4h = —_ = — <- «- oo 
S SL ( 
where T indicates the estimated time fcr programming. kee 


cept for the Stroud number, all parameters on the right side 
of the equation are directly measureable for any implementa- 
meen ct an algorithm. Research methods using calculated T 
valu¢ss have shewn that a strong correlation exists with the 
actual «ime measurements in the absence of certain "impuri- 
ties" which correspond to common undesirable programming 
practices such as unstructured code, low module cohesive- 


ness, high module coupling, etc. [8&1]. 


More recently, T. McCabe {82] developed a complexity 
d2finiztion based on the decision structure of a progran. 
McCabe's metric is the classical graph theory cyclomatic 
number v(G) defined as: 


v(G) = number of edges - number of nodes 
+ 2(numbter of connected components). 


Two simpler methcds cf calculating v(G) are presented by 
McCabe: the number of predicate nodes plus 1 or the number 
of regions computed from a planar graph of the control flow. 

Eicecally, this complexity metric counts contro. 


path segments which, when combined, will generate every 


48 





possible path thrcugh the program. Since additional control 
paths could make a program more difficult to understand, the 
number of basic paths indexed by this metric may also relate 


*o mental difficulty of a programming task. 


Ber ERROR PREDICTION 

If managers knew how a@ program behaved for every con- 
ceivable ccmbination cf inputs and could accurately predict 
all future input combinations, then they would knew precise- 
ly how many errors are in that program and could predict at 
which point in time that the program would next fail. Asa 
result, it would be fairly simple to program resources for 
software maintenance. The only real decision, then, would be 
wheather the annoyance from the error was worth the effort to 
eliminate it. Because this ideal situation is not a realis- 
tic representaticn of the world, except in the most trivial 
programs, it would ce a great aid to managers to havea 
method to predict residual errors with a reasonable degree 
Seecettda2nty. This capability would arm them with a good 
guide for frogramping the amount of maintenance effort need- 
See res fie next tie period. 

In the early days of computing, managers obtained rough 


estimates of the number of errors in a module ty assuming 
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Perce ~-nelre WwaS one Eug in every sixty lines of code or 
perhaps in ¢very cne hundred lines of ccde depending on each 
Manager's optimism and experience [83]. It seems to be a 
reasonable assumption that there is a ketter way to predict 
residual errors. The impertance of error detection analysis 
nas been recognized in the past few years and many studies 
have addressed this problen. med, 85, &6, 87, 88, 89, 99, 
91] An important objective of most of this work has been 
to develop analytical techniques to examine the error phe- 
nomenon in crder to compute or predict items of interest 
such as the number of errors detected at time t, the pre- 
sumed number of remaining errors at time t, and the software 
reliability function. (It should be noted that none of 
these studies deals specifically with the detection or the 
prediction of errors during the maintenance phase of the 
Boreware life-cycle.) 

One would expect software reliability to improve with 
age because latent bugs are detected and are presumably cor- 
rected. However, there are exceptions to this general state- 
ment. Bugs can tke induced into pregrams while corrections 
ase besng made. This situation, called the "ripple efiect", 


generally happens in very large systems like 0/5360 instead 
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Of small systems like a compiler (92). When a change is 
made in module ‘A’ it affects the way module 'B’ works. The 
Maintainer has néither the desire to change another module 
nor, probably, any idea that his change would affect anothez 
module. With vast, complex systems it is impossible for any 
person to know all of the ramifications cf a change. Since 
most operational software is subject to enhancements aad 
changes in requirements because of the dynamic environment 
in which it is run, it can be expected that bugs will be ina- 
duced with the néw code and that other modules will be af- 
fected through interfaces with the new modules. In the long 
run however, it appears that most software projects follow 
the predicted prcecess and have fewer errors as time elapses 
{93}. Table III [94] provides data to support this phenonme- 
non. Observe the great variability of the data and the in- 
creased reliability as time passes. 

Although the code appears to become more reliable as 
time passes, there are still problems with error prediction 
models. Many of these models assume a constant 4rror rate 
meso, 21, 98, 99}. This does not strike one as being a 
reasonable assumption on three accounts. First, the failure 


crate will fluctuate because the frequency of executicn of 
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the areas cf codé varies. Some areas may never be executed 
{100}. As an example, if one assumes that there are one 
hundred bugs in a program, that the failure rate is fifty 
failures a week, and that one is using a constant error rate 
prediction, then after fifty bugs have been elininated the 
failure rate should be to be twenty-five failures per week. 
If the bugs are eliminated in the order that they are de- 
Becesa, che first fifty tc be eliminated would be in the 
mos<t frequently exercised areas of code and the observed 
failure rate would be less than twenty-five per week. ce 
on the other hand, the most severe errors were corrected 
first, there may be a situation where there are several an- 
noying but non-critical bugs ina highly exercised portion 
of code and the cbserved failure rate is forty failures per 
week despite having eliminated fifty bugs. 

Second, according to Ottenstein [101], the error rate 
for modules, at the validation and integration stage, varies 
inversly with the size of a module. This theory has been 
corroberated by Motley and Brooks {102}. Motley and Brooks 
meeietnes this inverse preportion is an indication that 


“he larcer nodules were not as fully debugged during the 
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validation and integration stages and would go into the op- 
2rations ard maintenance phases with a greater proportional 
amount of errors. Otténstéin explained the phenomenon in 
just the opposite manner. She feels that there is a learn- 
ing and retention benefit that operates with large modules 
and thus the larger modules will go into operations and 
maintenance with a small2r proportional amount of errors. 

third reason for a variable rate of errors at the 
validation and integration phase is also proposed by Otten- 
stein [103]. Earlier developed modules are more fuliy de- 
bugged in the initial testing because at that period in the 
project there is a lot of time and money to do the job cor- 
rectly. However, modules that are developed near the ena of 
a contract appear to be hastiiy and incompletely debugged 
before being submitted for validation bpecause both time and 
Homey ar> EUNnning out. The authors propose a corollary to 
this hypothesis. The more over-~budget and behind-schedule 
that a project is delivered, the higher should be tne pre- 
diction of errors detected in the mainténance phase. 


Even if a manager could accurately predict the number of 


ct 


errors that will ce detected in a given time period, there 


would still be a croblem in scheduling the proper amount of 
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resources. Different types of errors will require different 
amounts of effort for cerrection because they are of differ- 


ent complexities. 


H. CHAPTER SUMMARY 

Numerous software tcepics are under study in an attempt 
so uncover explanations for the phenomenology of the soft- 
ware life-cycle. Of more specific concern are the events 
which lead to the increased expenditures during the opera- 
«ion and maintenance phase of the software project. Indica- 
tions from research evidence are that not one single factor 
can be named as the dominant contributor to the life-cycle 
Maintenance costs. Instead, a multiplicity of factors are 
cited as having an impact on the total systen. 

Recognizing the futility of identifying a single con- 
*ributor, xreseachers have resorted to finding the control 
2lements that best define the changes that occur in systéen 
characteristics. With a continued research effort, better 
understanding and increased familiarity of these system con- 
=rol elements may lead tc positive results in linking sys- 


sem characteristics with maintenance requirements. 
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Coupling the rising costs of computer software with the 
relative decline in computer hardware costs would indicate 
that computer software acguisition cost and maintenance and 
operation cost (collectively referred tc as software life- 
cycle costs) constitute the greatest share of the data pro- 
cessing budget. Conseguently, predicting future software 
costs for both existing systems (maintenance and operation 
costs) and new developmert is of increasing concern to 
management. 

The phenomenology of tne software development and 
Maintenance precéess is not definitively known. Researca 
Suggests the existence of a fairly clear time-varying pat- 
tern such as a Rayleigh curve or scme cther similiar form. 
The analysis is complicated by the presence of "noise" or 
stochastic components. Additionally, the okservable compo- 
ments (Manpower, cost, time) are strongly subjected to man- 
agement perturbation. This would indicate that although a 
Sviemem fds a Characteristic iife-cycle rehavior, if that be- 
havior is not knewn to managers a priori, then they will 
t2spond reactively (non-optimally with time lags) to system 


demands. A reascnakle basis now exists for expecting zhat 








an adequate phencmenological description may arise from the 
Following sources; 
1) statistical nechanics; 


2) information theory coupled with statistical comaunica- 
zron Cheory ; 


3) diffusion and transport theory. [104] 
ieaekeng OL Costs threughout the life-cycle is important 
because, as pointed out in chapter Two, sixty percent of the 


life-cycle effort is consumed during the operations and 


Maintenance phase. If this phase is treated as a level-of- 
effort task, then far more resources than necessary for 
Maintenance are used. Given a fixed manpower or budget 


constraint (very common in government), less than optimal 
control of the werk during this phase increases the possi- 
bility of maintenance work saturation (i.¢. devoting all re- 
sources to maintenance). This Situation leaves no capability 
=o accomplish additional werk. 

Within the scope of this discussion, three types of 
models for addressing maintenance cost estimaticn will be 
considered: 


1) software cost estimation from a macroestimating view 
using the Nerden-Rayleigh curve parameters; 


2) software cost estimation from a microestinating view 
using a work breakdown struccture(WES) methodology; 


By are evoluticn dynamics using system complexity as 


oye os 
Gao. MONItoOr. 
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The Sormat of presentaticn will include a general descrip- 
tion of the model with subsequent application of the model 


to the forecasting of costs within a maintenance scenario. 


A. SOFTWARE COST ESTIMATING MODELS 
a. Description 
This model attempts to provide quantitative an- 
Swers to the guestions often asked by managers about soft- 
Ware projects. These questions are generally concerned with 
project time duration, total cost, and the accuracy of the 
figures presented. Putnam's [105] methcds provide estimates 
in the following areas: 
1) Total lite cycle effort in manyears; 
PumeGGse  2Or the project; 
3) Peak manpower needed; 


4) Manpcwer needed at any specific time or phase in the 
project; 


5) Risk and variance analysis of derived estimates; and 


6) Linear programmirg (LP) technigues to impose real world 
Management ccnstraintws. 


Putnam's contribution tc software cost estimat- 
emgewds) te apply the Rayleigh curve to software iife-cycle 


manloading. Using the techniques based upon the life-cycle 
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*heory developed by Norden, Putnam did a number of empiri- 
cal studies and found that the software life-cycle exhibits 
a rise in manpower up to a peak and then a trailing off. 
Basically, the Putnam model cbtains estimates of 
the measure of work in man-years and of the total develop- 
ment «ime of the project. Development time in the Futnam no- 
del is defined as the elapsed time oon the project up to the 
point when the system reaches full operational capability, 
but not including the system definition and functional 
design/specification phases. The estimates of the total life 
cycle in man-years and the development time are then used to 
derive an eguation giving the ordinates for a man-power ex- 
penditure curve for a specific project. A yearly dollar 
costing can then be computed for the project by muitipying 
the ordinates cf the man-power curve at each year by the av- 
erage cost/man-year +O arrive at a dcllar cost/year and, 
mmoscedu-nuly, ac a tctal dollar cost for the project. Pe 
nam uses the Raleigh eguation, which has been empirically 
determined to fic the project manpewer loading profile for 
large projects and tc best represent Nordents model. The 
most popular form of the curve is the derivative form and is 


expressed by: 


a 





y' = ina (3.1) 
where 
y‘ = the number of man-yeazrs of effort expended per 
year, 
K = the total number of man-years required during 


piewlitcsevele of the project, 


a = the curve shape parameter, 
t = the elapsed time in years, and 
e = the expcnential function. 


With the assumption that the shape of the curve 
moescmenow related te both the difficulty of a particular 
development and to the skili level of the project team, a 
means for expressing these relationships in terms of Ray- 
leigh curve parameters was derived. The relationship of the 


parameter a to development time (t ) is: 
d 


2 
a= We (352) 


which, when substituted into the derivative form of the Ray- 
tetvoh curve, results in the following equation: 
Z 2 
~(t /2t_) 
Z qd 
7 = K/t te (33) 
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To use the above equation, estimates must be 
found for the tectal life cycle in man-years (K), and the 
development time oo Virtually every parametric software 
cost model is based on an estimate cf computer program size, 
measured in either source statements or object code instruc- 
eLons. Putnam uses source statements because that is what 
programmers produce. Likewise, it simplifies the mathemati-~ 
cal computations because compiler efficiencies are not con- 
sidered. The relaticnship that is used by Futnam to ¢quate 
source statements to development time and project effort is 


jiven by the following equation: 


(1/3) 
Ss = Ck*K = (3.4) 
where 
Ss = delivered source lines of code, and 
Ck = state-of-technology constant. 


Within the model, estimating program size is 
viewed as an it¢zative precess that should be recomputed 
several times during the system definition and functional 


design/specification phases in the software life cycle. The 


rh 


done at project conception and can be lit- 


fF?) 


Sti mace i 


L-st 


(WD 


ct 


le more than a best guess used te establish basic economic 
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feasibility based on past software projects and expert opin- 
ion. AS more knowledge is gained about the project, indivi- 
dual segments of the system are estimated seperately and 
then cotaled to give a more accurate estimate of the expect- 
ed size. Also, standard deviations and confidence intervals 
are derived from statistical nethods that use best and worst 
case estimates. 

To determine the technology constant, data from 
past software projects must be inserted into the software 
equation (3.4) tc derive the unknown variable Ck. It should 
b2 noted that Ck is initially very difficult to determine 
but should remain consistent for similar projects within a 
spécific organizaticn. After the parameters Ss and Ck are 
determined, varicus values of os and/or K may be substituted 
into the software equaticn to produce a parametric graph 
showing size versus effort and time (figure 3.1). 

A constraint line determined by management and 
representing a difficulty gradient for certain types of pro- 


cts is then superimposed on the graph. Values tnat fail 


USi5 
(D 


below this line are determined to be infeasible fcr software 
developmen. 


After values and ranges are found for E ang K, 
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Systen Size x 10 
Figure 3.1. Siz¢ vs. Effort and Time Relaticnship 


dollar costs for the project may De computed by nultiplying 
plying an average labor rate per man-year Dy an expected 
value of man-years tc derive an estimated total cost for a 
project. A variance estimate for dollar costs may be ob- 
tained in a similar manner from the variance orf man-years. 
Ahile this aodel recognizes that real world managerial 
constraints exist, they are not explicitly addressed. In- 
stead it is recemmended that linear programming technigues 


should be used to account for everyday concerns such 2s 
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Senmtrac. deadiines, cost ceilings, and feet practices and 
@emabilities. 
b. Application to Maintenance Costing 

Putnam's model takes a macro approach to answer- 
ing the questions mcst often asked by managers concerning 
the areas of time, effort, and cost. According to relation- 
Ships détermined empirically, an overall estimate of man 
power is obtained and subsequently allocated among the 
different phases. To détermine the risk involved in the es- 
timation, statistical methods are used which give the manag- 
er a 'feel' for the accuracy of the data presented to hin. 

As werk preceeds during the life-cycle, uncer- 
tainty about the management parameters cecrease. In order 
zo follow and track the time-varying behavior of a software 
system, empirical data must be collected and plotted to show 
eimencudrcen= iabor force for any given time (figure 3.2). 
Using this data stream, time series analysis can be done. 
By turning the characteristic Rayleigh behavior into a 
straight line, the actual manpower data may bre fitted to get 
a revised estinate of future resource consumption. 

The linear form of the Rayleigh-Norden curve is 
Mmemcemated in figure 3.3. This form may be obtained by di- 


manemaqerequac:on 3.3 by t and taking the natural logorithm of 


o4 
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the result. This yields 


he W: 2 
Ln(y'/t) = Caco yt + Ln(K/t ) (3.5) 


which fits the familiar linear form v = mx + b. 

Actual data is set up in a table form with addi- 
tional calculated data points that are needed for the cor- 
m=spenaing plot. Hypothetical data from Table IV is plot- 
ted in figure 3.3 with the best straight line fitted to the 
data points (determined by eye or calculation). 

From this plot, Rayleigh parameters can be cal- 
culated. The slcpe can be used to compute development time 
ee while the intercept a ), given the value of 7 
just obtained, yields the value of total effort, K. Caicu- 
lations for determining these values are listed with the 


Pagure. 
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FABLE LY 


Hypotheical Project Data 


ao YS Tie t La(y*/t) | 
eet aas Gea casaeaee ects | 
t 1 68 68.0 1 4.22 | 
in 2 70 35.0 4 35D i 
Ly 2 106 35.33 2 3.56 | 
| 4 118 29.50 16 5.30 { 


Prcjected management estimates can be calculated 
py extending the line to subsequent year points (figure 
Bad). Continuing with the same example data, future man- 
loading predictions are made by applving the sequence of 
eguataons contained in figure 3.4. 

Similiarly, resource estimation for additional 
outyears may be computed. AS mentioned earlier, this model 
is an iterative procedure. Each year actual project data is 
added to the table. The data points are replotted and che 
best fit straight line is again determined. New values for 
the slope and intercept are found and frojections are then 


made based on «hese new values. 
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Figure 3.4. Line Extension and Frediction 


2. AEmy Macrcestimating Model 
a. Description 
Realizing that there was a need for a simple, 
etfective, reasonably accurate procedure for estimacing and 
controlling resources, Army Headquarters analysts produced a 
comprehensive macroestimating procedure for allocating tne 


* 


appropriats manpower cOmmit#ent to an application system at 





miveepeane in the system life cycle [ 106]. The procedure 
Siam =eS USers tc forecast the size of a new application 
software project and suggests the manlcading necessary to 
accomplish the preject workload. 
Some functional estiaators for the project man- 

ager include: 

1) optimum man-loading over life-cycle; 

2) total manpower over life-cycle; 

BipcOSe Der year; 

4) risk frofilés;and 


5) scope of applicability. 


Initial analysis of all United States Army Con- 
puter Systems Ccmmand (USACSC) systems yielded a database 
from which statistics have been derived that permit estapn- 
lishment of control limits on resource allocation at any 
point in the life-cycle of a system. Additionally, numeri- 
cal correlation points between effort/unit time and nornal- 
ized time were estaklished for system develcpmen= nile- 
stones. Using these pecints, the project manager can plot 
Siemprovec= Lite~cycle profile of a software development ef- 
tort in terms of the time that various milestones should be 


reached and the level of resources (manpcwer) that should be 
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applied to the system development at those points (figure 
Br). 
Excursions outside statistically determined control limits 
Snowiodgnmes t2gure 3.5 should trigger the action officer to 
eoikee COFZeECtive action. 

Using the mathematical relationship developed by 


Norden, 


y' = 2Kate (34) 


Step-by-step procedures were developed fcr estimating systen 
variables for the following cases. 
(1) Case I: System already under development 


(resources budgeted). Using budget data, the maximum level 


of manpower(y' ) and the number of years to reach maxiaguno 
max 


Secor t (= ) is determined. Rather than compute the values 
g 


max 
for outyear manpewer loading, Table V is used to compute the 


values of y' for the appropriate t - By multiplying any 


7 
max 


2nery opposite its time period by K, the appropriate number 
of manyears are cbtained. The units of K and t will deter- 


Mine the demensicss. 
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DeoueN CeRTIFICATION 
mee oe O'ez35 
expected 0.433 
last 0.618 


Sroiens PNIEGRATICN TEST 
Eins < 0.550 
expected 0.660 
last 05 766 


BPOTOTYPE EVALUATION TEST 
Pees 0.613 
expected 0.800 
Past 0.990 


Exec eENSION 
first Ovo 
expected 0.930 
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rasSct 22076 
expected Zita 
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Nore 1: Bao ANG Atase sabe at fivewpercent probability hev- 
Sec. moece 1S @ ALNetY percent probability chat 
t/tymax (ewe Deseween Tiost and las< tora par- 
ticular milestone event. Tf net, ask questions. 


WOTEe 2: Tabuiar entries are in norzaalized time units. 


Figure 3.5. Milestones Applied to Froject Profile 
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TABLE V 


Ordinates for Manpower Function 


= | t eq 2 g 4 3 6 7 
ee eee 
O| Set 320 et2o0) 0956 2.0310 .0200 .0139 + .0720 | 
a a ee a a et eee ee we 
1| mOUGOG).2c0026.10510 .0605/ .03920°.02739 .02020| 
2" | 27067 .30326 .17794 .11031 .07384 .05255 .30918] 
3| ~Osoo2 624949 220217 .14153 .10023 7.07354 205565 | 
4 | SOU da |coosemeroz7 | «15163 .11618 .06897) .06933| 
oa 00001 .05492 .13852 .14307 .12130 .09814 .07906| 
6 | -01666 .09022 .12774% .11682 .10108 .08480| 
7 | 00382 .05112 .09461 .10508 .09845 .08664| 
8 | 00067 .02539 .06760 .08897 .09135 .08497| 
a -00009 .01110 .04475 .07124 .08116 .08036| 
10{ -00000 .00429 .02746 .05413 .06926 .07356| 
a ~-00000 .00147 .01567 .03912 .05691 .906530| 
12 | -00044 .00833 .02694 .04511 .05634| 
13 | 00012 .00413 .01770 .03453 .04729 | 
14 | -00002 .00191 .01111 .02556 .03866| 
15 | -00000 .00082 .00666 .08130 .03081| 
16 | -00000 .00033 .00382 .01269 .02395| 
ey 200012 2.00210" .00653 201317] 
18] ~-00004 .00110 .00555 .U01346| 
19 | -€0001 .00055 .00350 .00974 | 
20 | -00000 .00026 .00214 .00689)| 





(2) Case II: New system (no resource data). 
Total man-years of effort and peak time for manpower loading 
is estimated using Bayes' theorem. [107] Based cn empirical 
data from internal systems, a preobabiiity versus K density 
function was derived witnout regard to type of systen. 
Further analysis determined frequency of system type and 
probability of cccurence of each type. Using estimates 
based on past USACSC experiences the average K valus for 
all systems under development and average K for the func- 
tional type of system), initial estimates for a new new de- 
velopment are calculated from regression graphs. Then, by 
applying Bayes’ theorem tc average these individual esti- 
mates in the weighted probability sense yields a better es- 
cimate of K with a smaller standard deviation (i.2. better 
confidence in the estimate). To improve estimates and re- 
duce uncertainty, Bayes’ theorem is sucessively applied. 

Bees Delicatien to Macntenance Costing 

WSeese oNpteeecally decermined that all or their 
systems reached a steady level ot effort (maintenance level) 
on the average cf 2.38 times the amount of time that was 
used to reach maximum effort. This relationship can be ex- 
pressed as; 
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+ =" 2,50t (3.96) 
H+ ¢ 


In applying this equation, a system, with maximum level of 
erfort reached at year three, would reach a steady state at 
7.14 years. 

me level of effort associated with the steady 
state maintenance phase was empirically determined by USACSC 
+o be twenty-three percent of y' With a ninty percent 


Rax 


confidence interval from eight percent to thirty-eight per- 


Conv or. y' Mev ceudateroln:  2n) the project iLimte-cycle, 
max 
when eas ie (twenty-three percent of y' ) is reach- 
max max 
a, using numbers generated from the manpower equation 


(3.1) should be discontinued and a constant level of effort 

of twenty-three percent of y' should be used until the 
max 

system is replaced. Figure 3.6 shows a géneralized 


control-limit envelope of a ninety percent confidence inter- 


val for the resource ievel. 
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(ALLOCATIONS OF M-Y/YR SHOULD REMAIN oy /¥ =0.25 (USACSC DATA) 


WITHIN THESE UPPER AND LOWER BOUNDS is 


1.6 0, ,/Y = + 0.40 


DIMENSIONS ARE IN NORMALIZED UNITS TO 
DETERMINE TIME FOR ANY SYSTEM, MULTI- 
PLY BY Gye: TO GET MAN-YEARS, MULTI- 


PLY BY Y'_y: 
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BE BELOW THIS LINE. 
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Figure 3.6. System Resource-Control Limits 


B. SOFTWARE EVOLUTION MODEL 


ApDesCription 
There have been severai attempts made to assess 
rasource alilocaticn to achieve the repair or meodification 


required for a single release, which is a new version of a 


v2 


nad 
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Ssystan. A variety of data has been collected relating to 
module handle rate and release interval. Based on experi- 
ance in dealing with different environments, it has been 
suggested that development and maintenance trends exist giv- 
ing rise tc complexity measures. Thesé measures, in turn, 
can be determined by the average number of old module han- 
dlings per new mcdule and per fault fix, respectively. 

As systems evolve over a series of releases, the 
ratio of changed modules to the total number of modules have 
been found to mcnotcnicaliy increase and approach unity. 
This ratio is an observed and directly measurable guantity 
which describes the system's property of resistance to 
change. Of importance is the indication that the number of 
modules involved ina system modification is likely to be 
Pmepore tonal to the effort spent. [ 108, 109] 

Belady and Lehman proposed a model in which ac- 
*ivity is of three kinds: progressive {F), antigressive (A), 
and additional work related to system ccmplexity (C). ic 
was hypothesized that a balanced budget (B) ‘iaplies that at 
any time 


Bee Pe * A. + C. (3.7) 
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Although simple, the model captures two important aspects of 
evolution dynamics; the sharing of the resources between 
progressive and antigressive effort (where both A and C are 
considered antigressive) and the absorption of total budget 
and further growth limitation by the inevitable rise in the 
eost Gt complexa<y. 

Increase of C activity is hypothesised to sten 
from neglect of A activity. Removal of resulting cumulative 
neglect can be accomplished only by a temporary increase in 
ae If the total budget, B is limited, the result is a tea- 
porary decrease in pregressive activity, P. It is assuned 
shat B, P, A, andcC can Le measured in cost per unit time. 


The cost function is expressed in the fcllowing fashion: 


Cost (t) =f - am KP ar (3.8) 
where 
KP = inherent A activity required for each unit of 


P activity to prevent complexity growth; 

m = management factor, the fraction of KP actuaily 
dedicated by management to A activity (O<mi) ; 
and 


T= a cime constant. 





D. Application to Maintenance Costing 

Preliminary analysis and simulation have been 
carried out using a non-linear differential equation nodel 
of evolution dynamics. it has been found that the model is 
capable of reproducing some important phenomena observed in 
data that can be related to observed characteristics of the 
system. 

in bebe s367, 1. the sinuletion shows that the 
code production rate (the progressive element) increases to 
a maximum of about 225 modules per year. At the end of the 
first year, the complexity has increased to the point where 
such a production rate cannot be sustained with the budget 
available, since an increasing resource demand is being meade 
by A and C activity. A balanced budget requires a reduction 
in P activity, which later leads to a reduction in A activi- 
Ci. By year six, the system has reached its ligziting size 
with the resources available. 

Although results seem promising, a great deai of 
work must be done befcre practical results in the form of an 
accurat? predictive model can be achieved. From figure 3.7, 
it would seem apparent that application of control theory 
*o modules developed earlier may result ina substantial 


payoff in financial <t¢ras. 
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Total size (modules) 


Complexity 





| Growth rate (modules/year) 


Time (years) 
Pigure 3.7. Grewth Rate Simulation 


ae Descripticn 

Putnam and Norden have prepared a Rayleigh curve 
model for the rate at which resources are consumed by soft- 
Ware engineering projects. One of the model's main assump- 
tions is that the initially rising werk rate is due to a 
linear learning curve governing the "skill" availaole for 
solving problems at time t. This assumption is questionable 
pecause a linear learning curve is not theoretically sup- 
ported, and the skill available on a project depends on the 


crescurces which have been applied to it [110]. Thus, this 


ass 





Sssuspe. Oh COnEUSeS Intrinsic constraints on the rate at 
which software can be produced with management's economical- 
ly governed choices on how to respond to these constraints. 
Parr asserts that the rate of progress on a 
softwar? project is primarily determined by dependencies 
among the problems which must be solved. Some problems can 
be solved in parallel whereas others can only be handled se- 
guentially. Let W(t) be the number of problems which have 
been solved at time t and V(t) be the number of visible un- 
solved problems at time t which can be solved (i.e., all 
zarlier required froblems sclved). When a problem is solved, 
A(*) increases by 1; V(t), however, may increase or decrease 
depending cn whether or net the froblem solved makes new 
problems invisible/solvabie. It is reasonable to assume 
that problems solved sarly in the fproject will lead to more 
unsolved problems, and that those solved later will have a 
higher probability of not making new unsclved problems visi- 


pace’. A crude approximation to this is to assume that the 


th 


probability of a solved preplem not generating more unsoived 
problems is iinearly proportional to the number cf problems 


solved. f[ 111) 
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How does the above relate to the rate at which 
development programs can be made? Clearly, management can 
reduce the rate of frogress by supplying inadequate re- 
sources. There is alse an upper bound to the amount of ef- 
fort which can be usefully applied. Rapid progress using 
large amounts cf input resources is possible only when there 
memseOpe £Or sclving preoblems in parallel. In practice, a 
different programmer (or possibly &@ team of programmers) can 
be assigned to each separate visible unsolved problem. This 
Suggests that the rate at which useful work can be applied 
memonooorcLOnal to V(t), and that with this “optional" input 
affort, steps in the development will te achieved at a rate 
BeOpOrclOnal to V(T). 

Whereas the Rayleigh model proposes that che 
rate of progress will be preportional tc the skill level and 
number of problems remaining, the above has argued that it 
is proportional to the visible unsolved problem set. A 


mathematical expression yields: 
2 
V(t) = (1/4) sech ((t + eee (gr. 9} 
eee peeroerc Lunceton Symetric in t with an integration con- 


stant c ; while the Rayleigh function is: 
3 


No(e}) = y* = te | 63% 10} 








The Bene. model closely resembles the Rayleigh nodel in the 
datter halt of the curve, but the front tail is positive 
moenert chan zero like the Rayleigh (figure re ieee Segue). 
tne ee. model, projects dc not have well-defined starting 
Memento. This acccunts for work done prior to the official 


project starting date. 
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Pigure 3.8 Sech Curve 


One cf the principles of software programming is 
that decisions initially made should te high-level struc- 
tured ones which identify components for subsequent zsefine- 
ment. Incréasing the complexity or the initial decisions in 
this manner is eguivalent tc varying the distribution of the 
probability or a solved problem generating unsclved ones. 
By modifying the assumption that this prebability is linear, 
a modified workrate functicn can be derived: 
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WCE) = A_exp_ (-2_9t) feed) 


=a a a es 


(1 + A exp (-2e/t)) 

Thus, it may ke seen that whereas the Rayleigh 
model of scftware development proposes that the rate of pro- 
gress will be proportional to the skill level and number of 
problems remaining, this section has argued that it is pro- 
portional to the size of the number of the visible unsolved 
node set. 

Results obtained from the proposed model are 
Similiar to the Rayleigh modei, except that account is taken 
Ssvomercontributing to a project which precedes its offi- 
cial starting date. The proposed model has been shown to be 
sufficiently determined for it to be possible to account for 
“he effect cf different prcgramming methodologies on the na- 
tural work associated with the project. 

b. Applicaticn to Maintenance Costing 

Parr suggests that exhaustion of the problem 
spac? 1s the main cause for decrease in maintenance effort 
at the end of the project profile curve. inNeaadac2on, cac 
Structure of the software product achieved during the devel- 
opment could affect the project work profile. While appli- 


Cations to maintenance ccsting have been addressed in 
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eencepe only, implications are that integration techniques 
for determining the area under the curve at a specific time 
pe- riod will produce results similar to those obtained by 


uSing Putnam's model. 


eo Cie t eR SUMMARY 

With the intent to gain management cecntrol of predicting 
Maintenance costs, various software cost estimating methods 
and philosophies derived from observing trends and patterns 
in the development cycle are being extended to encompass to- 
*+al system costs. Supportive evidence for the accuracy of 
the models discussed herein is contained, for the most part, 
in software life-cycle simulations. It is anticipated, how- 
ever, that the acute interest and incréased awareness skown 
in the rescurce investments attributed to software mainte- 
Rance Will be viewed more critically. Although lacking in 
substantial procf for predictive validity, these models 
serve as stepping stcnes in producing a composite model for 


eeaicwenG maintenance costs. 
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IV. MANAGING SOFTWARE MAINTENANCE COSTS 


a = =—=_ = >= == 


Previous chapters have addressed topics that are being 
critically examined for their impact on the software mainte- 
mance phase. They also discussed the application of current 
development software cost estimation techniques for obtain- 
ing maintenance costs. PicerOcwus OL this Cchapterewid)) pe 
the presentaticn of a method for arriving at a well- 
Structured view of the management of the maintenance phase 
of the software life-cycle. While a mathmatical model which 
accurately explains the phenomena of the maintenance phase 
still remains elusive, a planning and control model has bes¢na 
developed +o aid project managers. fhe structure of the no- 


d2l embodies two distinct concepts: 


1) a@ planning cencept - development of the management 
Strategy to cement the perceptions of the maintenance 
issue; 


Zicmeemeroluecencept - “procedural analysis for estimating 
the maintenance manloading requirements. 


Subsequent sections will address application of each as- 


pect of the model in depth. 
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A. PLANNING CONCEPT 
1. Projects Management 

Primary responsibility for develcpment of a manage- 
ment strategy belongs to the project manager designated to 
Manage the system plan. AS project manager, one must ini- 
tially determine and d¢efine the maintenance requirement of 
the mission profile for the system that is to he designed 
(i.e. built-in maintainability). 

Factors which must be considered early in the fornu- 


lation of a maintenance plan include: 


1) Probability of change in requirements. While it may be 
impossible tc define adequately the complete require- 
ments for a large progran, viewing the type of systen 
application (business, scientific, command and ccentrol) 
and utilization rate will serve as indicators for the 
amount of flexibility to be considered in the system 

esign. 


2) Software performance requirements. Agdti dp PL Gatelon 
type is the dictating force for analyzing this factor. 


yee ckawdre 11te-Ccycle.s ~ In pranning Lor software mainte— 
Mame, the interacticn o tne nardware and software 
life-cycle must Fe taken intd account. 


2. Objectives of the Maintenance Ccncept 
Derivaticn of maintainability requirements from the 
descripticn of the cperational requirements provides tne 
Support planning criteria oon which to base the maintenance 


concepts appropriate to the maintainability requirement. 


The maintenance concept, which basically defines criteria 
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governing the sccfe and methods applicable at each echelon 
of maintenance, attempts to satisfy the quantitative main- 
tainability requirement derived for the system and the plan- 
nea support environment within which the system will oper- 
ate. Early development cf the appropriate maintenance 
concept will provide a definitive and uniform basis for ac- 
complishing the system design and support planning tasks. 
3. Establishing the Maintenance Policies. 

System effectiveness is jointly dependent on several 
parameters, of which performance characteristics, system re- 
liability, and operational availability appear to be the 
most critical. In effect, these parameters set baseline re- 
quirements or constraints which may have impact upon the de- 
sign process depending upon the maintenance policy chat has 
been established. While a boundless number of pceclicy varia- 
tions may exist, the following four categories identify the 
Bangemor policy choices. The basic distinction among these 
four categories lies in the amount of resources invested 


over time and the cumulative benefit received over time. 
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a. Category I - No Management Ccntrol 
A steady maintenance effort is applied with no 
attempt for configuraticn control which is ensuring that a 
Master copy of ali operational software is maintained. Coan- 
plexity of the program will eventually reach the point where 
locating errors and/or making changes becomes exceptionally 
difficult. Gradually, the program becomes less useful until 
it must be discarded and anew program developed. This 
policy may prove to be cost effective for situations where 
it is known that the nature of the application will limit 
mee Usetul life cf the pregraa. 
D- Category II - Permanent Support Level with 
Pericdic Redevelopment 
As in Category I, a steady level of maintenance 
Support is provided by a permanent workforce. Redevelopment 
or a new release can be planned for at regular intervals oz 
in response to a specific quantity of change requests. 
c. Categery III - Error Repair with Major Changes 
Manpower support is set at che level needed to 
correct program tugs. External programming support would be 


required for making major changes. 
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amecacegory MWye- Erzvor Repair Only with™ Periodic 
Redesign 
As in Category III, manpower is set at the level 
needed to correct an unacceptable design error or progran 
bug. Change requests are used in establishing specifica- 
tions for subsequent design of a new progran. 
4. Management structure 
Since the level of repair fpolicy must be compatable 
Peo ohem@m@aintainabil*ty requirement, he maintenanee con- 
cept must te defined for each management level of mainte-~ 
nance established. Beginning with the lowest level of us- 
SES, maintenance concepts are implemented with subsequent 
policies for higher management levels developed to support 
the user level concept. To illustrate, maintenance may be 
divided into three echelons as discussed below and shown in 
Segureasd.1. 


1) User level. Maintenance may be restricted to failure 
reports and system restarts. 


2) Organizational level. Technicians per 
Maintenance. Tasks performed would incl 
fawec, Module repair, and testing 


form corrective 
ude location ofr 


Sy Gon ~nacter level. Maintenance performed at this level 
may be used to supplement (augmented support Ofte 
replace (sustained support) the organizaticna level 
Suppers =. 
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| Recivity | User organization| Contract | 

| Level Level Level 

le a eS de Wee 

| | beracalaty | Agency and/ | 

| Where | Remote or { having { or contract 

| performed {| local site | project Petacioetrcs., | 

| | cognizance | as required | 
nee | ee a ee 

| Maintenance 

{ Whe performs{ Maintenance |{ division or Con crace | 

| | perscnnel | Support téam{ perscnnel 
~--—------—-- | --—----—----- } -----------— ame —— 

| Restcre | Locate mcd- Locate mod- | 

{ Maintenance | system to { ule errors; | ule errors; | 

| gle tion | Operationai | repair and | repair and | 

status return to return to | 

user user 

| a | a | 

| Inspection | Module | Complex 

| | and restarts| repair; ._. repairs, 

Minor major coding] modifica- 

| Maintenance | repairs and | modifica- (ectens: “Rajon | 

| tasks | adjustments | tions, Pe codana: 

| | submit testing | rebuilds | 

change 
| {| requests | | { 
| | | 


Figure 4.1. Maintenance Levels 


Utimately, the naintenance objective is to achieve 
the required level of maintainabiiity in delivered systems 
with an optimum balance between resource support require- 
ments and potential life-cycle costs. In order to meet this 
objective, it is necessary to begin the system life-cycle 
With the appropriate conceptual approach. As the software 
product passes through several distinct phases in its evolu- 
tion, maintenance prospects can be enhanced if adequate at- 


tention is «<aken in each phase. 
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Figure 4.2 depicts the life-cycle as a simple 
phase-to-phase flow diagram, joined by critical transition 
points where it can be ascertained that the required main- 
tainability objective has been achieved before transition to 
the next phase. These transition points are denoted in the 


figure as major achievement milestones. Each phase compris- 


(D 


S$ severai areas cf management endeavor in which the consid- 
eration of the system maintainability is essential to the 
attainment of milestone objectives. The software product is 
re-examined at each milestcne to determine the future course 
based on progress up to that point. As each milestone ob- 
jective is met, maintainability becomes progressively nore 
*angible as a built-in feature of design. Maintainability 
Milestone requirements are summarized in tne figure. 
Milestone criteria can best be satisfied by syste- 
matic application of approved procedures in the performance 
of evaluation, Management, and control tasks which are 
geared directly to specfic objectives of individual mile- 
stones in «he iife-cycle. A basic approach to maintainabil- 
f+y achievement as an evolutionary phase-to-phase ‘growth!’ 


process is shown in figure 4.3. 
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Concept Formulation Phase Milestone Criteria. Maintain- 
abllizy requirements derived; Maintenance concept estab- 
lished; maintainability documented in system specifica- 
*ions; mMaintainabiliity milestones and task requirements 
documented. 


(1) Proceed to design phase. 


Design Phase Milestone Criteria. Maintainability design 
approach and maintenance concept optimized by tradeoff and 
conformance Pe Sa ee ee eee and economic consid- 
erations; maintainability requirements and milestone 
criteria updated. 


(2) Proceed to code phase. 


Code Phase Milestone Criteria. Conformance tc specified 
Maintainability requirements and maintenance concepts ver- 
ified by evaluation; maintenance control procedures de- 
fined in support documentation. 


(3) Proceed to test phase. 


Test Phase Milestone Criteria. Maintainability degrada- 
tion factors verified by test and evalution; maintenance 
concepts, repair policies, and maintenance procedures 
are verfied. 


(4) Software product is approved for delivery. 


Service Use Phase Milestone Criteria. Haven tal Nagel ity 
Characteristics, maintenance prodecures, and support costs 
determined by periodic assessment cf Management data; 
problem areas identified for correction. 


ee Initiate change request, product enhancement or new 
evelopment; repeat life-cycle. 


Figure 4.2. Maintenance Milestones in the System Life-cycle 
BommcovenokL CONCEFT 
1. Objective of Maintenance Control 
The objective of this thesis was to develop a 
methodology for arriving at agcod preéedicticn of pure 
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| LIFE-CYCLE PHASE . 
| TASK AREA ceIDIC ITI S| TASK REQUIREMENTS 
i | { 9 Establish M policies | 
Determine | | © Derive M requirements | 
Dn terantaan- | | { | | { ° Optimize M to relia- | 
[abel t y [ee La | i | bility, availibiiity, | 
Require- { { i and supportability | 
| ments | | ( | | 9 evo Song epe ues ! 
{ eSign criteria 
-———__ooO° (7) TOP Too (Seep [$2207 =o SS See eee 
| Specify | | | { | °% Define M requirements | 
MmMaintain- i | {i ° Define 4 milestone { 
eaow ty | | { { criteria and task { 
require- | = * x | * | requirements in 
| ments and i peo Eas documentation 
| milestone | | iy wie? Specitically ouciline 
[i CGElteria | { | i | foregoing requirements | 
i i | | { { in contractual i 
| | | documents | 
| { ° Identify and define M | 
{ { | { prceblems and critical | 
| Achieve { i { areas { 
{ specified | { | © Integrate M énhance- | 
| maintain-~ | foe |e * ment into design | 
| apility | | | o a) design one eare | 
in design | suceace specific 
requirements 
{ | Q negey impact of poem 
| { { { ed eae Changes on H jf 
| i { | { : eSign characteristics | 
ne a a) alien (aa eee OOS ae OTTO oS 
| Show ade- 9 Prepare detailed plans 
| eal of mo for maintenance test 
Maintain- i 
| apie y 1h | {| ° Demonstrate adequacy 
{| develop- | | | of maintenance nanuals 
| ment | 
ae hl eee | ote | eames oe ee ee oe 
| | i { ° Develop maintainence | 
Achieve plan, repaizc Ere ce roa 
optimum | and procedures 
Mainte- { * * { * | *® [* | 9 Develop maintenance | 
nance i { training progran i 
suppor< i O Prepare contractor 
| Suopor -plah 
| ° Verify conformance to | 
| Evaluate | | | | M requirements under | 
| | | | { { service conditions { 
2 dente sn | i | | * | CMVNeGcsry Aagequacy Of i 
(armel at ¥ | i | | Maintenance suppor? | 
| | | | | manuals ; 
Qo 
{ at service { | | roy Evaluate skill 
{ { { | | | | requirements and | ( 
j level { ( \ i | adequacy of training | 
| ee ee reson Ae! 
CF = Concept Formulation CLC = Design 
C = Code. T = Test 
S = Service Use 


Figure #.3. Maintenance Tasks in the System Life-cycle 
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maintenance costs. Determining the requirements for pure 
Maintenance is considered valuable in that 


1) estimates can be calculated of the manloading necessary 
to fOrm,a Maintenance support team which is composed of 
either in-house or contract augmentation; 


2) projecticns can be made for outyear maintenance support 
ant eee on of manpower resources for developmen- 
Esai work. 


With future research, the application of this mnodel 
may be extended to any software project; however, access and 
availability of data precluded analysis of small and medium 
Sized projects. Only data from major projects was analyzed 
for developing a computational algoritan. 

In executing the computational algorithm, both macro 
(system) and micro (functional aréa component) techniques 
are used concurréentiy te increase the validity of the esti- 
mates. An implicit assumption worth noting is that each 
method should provide reasonably closé estimates for the 
Same project. The macro technique, of course, is based on 
total system characteristics and will previde the gross man- 
ning requirements directly. Alternately, from the micro 
technique, summation of the decomposed functional areas wili 


yield the gross manning for the total systen. 
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The data under study was taken from a large-scale 
project reported by USACSC [112] and unpublished data fron 
the IBM Space Shuttle Program {113}. 

a. Macre Technique 

Using the Rayleigh curve parameters derived by 
Norden and Putnam [114, 115], a method was constructed for 
Obtaining total system maintenance reguirements applicable 
to the established management strategy. In his early work, 
Norden made note of the fact that the Kayleigh curve of a 
project profile has a point of inflecticn at which the de- 
crease in utilized manpower slows down in the descending 
Beptr1on of the curve, 


Vf2 


3 
a "(a (4.1) 
al 2 


Eee tHe int eectl on point of the project curve 


the shapé parameter or spread of the curve. 


wy 
il 


Micmccinct = Ce warleceion may have more sagqpats- 
cance than originally recognized. hf it@ean pe shown chat 
the level of effort for the maintenance phase reaches a aax-~ 


imum at this point, the manlcading estimate calculated fron 
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this point can te used as the upper becund for maintenance 
support. In essence, the current model suggests a new 
mechanism for determining the level of maintenance support 
required. Gained from the model is the benefit of relating 
Semen wOrk profile more directly to the intrinsic structure of 
mee CEO ject profile. 

fo simpigety Calculations, the project profile is 
normalized with respect to t and y' as shown in figure 

d max 

Geet) Total life-cycle (K), has a normalized value of 1. 
Based on this assumption and using Rayleigh curve reiation- 


Ships, it can be Shewn empirically that the peak of mainte- 


Mamce €&LCrt Occurs at the inflection pcint. 


( yay" ) 
na x 






(0.25 5" ) 
aax 






mee oe Se cose s cena eee 
a 


= i t 


d “ip in 
Figure 4.4. Normalized Rayléigh Curve 
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From the normalized curve values, the shape 


parameter is found with the following relationship: 


Sa Tees SO. S (4.2) 


Substituting this value of a in the following equation, the 


mntlection point (t ) of the project profile is obtained. 


ip 
: Wz 
c =: ‘sia = 1.73 years. (4.3) 
ip 2a 
Manloading requirements at time t (y' 


) 
1p 173 
can be shown mathematically to be equal to the maximum nmnan- 
load (y' ) which occurs at the peak (t ) of the maintenance 
< 


1 
mi 


phase profile. Stated in the format of a mathmatical equa- 


*#i0n, this equality has the form 


(pEeoject inflecticn = (maximu@ maintenance 
point manning) phase manning) 
or ye va (4.4) 
o © 
ip m 


Substituting normalized values into the Rayleigh (manpower) 


2quation 


2 
(~.05) (1.73) 
DaeCnOS) (1273) (4.5) 


' 
5s Cr 3) 


Cis 23) 


0.38 manyears. (4.6) 
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In order to calculate maximum manning for the 
Maintenance phass, parameters for the maintenance curve must 
be defined. Actual time elapsed between the beginning of the 
maintenance phase (t) and the maximum level (t is comput- 
2d using empirical data recorded by USACSC. Results fron 
the USACSC research indicate that the maintenance phase, 
which accounts for twenty percent of the total life-cycle 
Manpower (K), bégins at approximately 1.3 years normalized 
*ime. With this estimaticn, actuai time elapsed (t ) can be 

= 

found by 


Se = t. ~- t = 0.43 years. (4.7) 
- M oO 


The spread of the maintenance curve (a) is 
m 
determined by subtituting the elapsed time value into the 


already familiar equation 


a = === = (Zoey (4.8) 


The value cbtained for the shape parameter suggests a curve 
having a wide spread, an expected characteristic of the 
maintenance phase profile curve. Computation of the maxiagua 
manloading for the maintenance phase from the basic manpower 


equation gives 
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(-2.71) (.43) 
Diets. 7 1) (. 43) € (4.9) 


bes 
i 


yt = 0.38 = y! C4 0 ) 


With y' defined to be the upper boundary for 


the maintenance effort, anether boundary can be identified 
as the lower limit for maintenance effort. By determining 
the value of the inflection point of the maintenance curve 
bce ), a minimum support level can te fcund fron 


3 1/2 
= = === = ./4 years. (4.11) 


7m za 
m 


Converting this time to normalized tine (+ ) 
n 


ee OR (4. 12) 


il 
aa 
e 
ty 
ae 
e 
~J 
_— 

il 


c 
Nn 


2.04 years (4213) 


and substituting this value in the manpower equation yields 


' ae = .26 manyears. (4.14) 
(2.04) 


The manpower loading calculated for the inflec- 

tion point of the maintenance phase (t ) closely approxi- 
im 

mates the value identified by USACSC as the steady state 


Meviemeor CLEOrt. Establishing maintenance at the miniaunr 


Wepeomecan 52 interpreted as a Categery IV volicy. 
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ee’ Mecre Technique 
Decomposition, more commonly referred to as the 
work breakdown structure (WBS) method, has been a predoni- 
nate methodology for estimating manning resources. A systen 
2s considered +o contain Subsystems which are further divid- 
ed into smaller hierarchial structures until the smalles< 
progrmming element is reached. Once the functional areas 
are defined, characteristics (complexity, productivity, er- 
more rate, etc.) of each must be reviewed to determine the 
level of effort needed for maintenance. Appendix A contains 
an example of a micro-estimating methodology along wita the 
Sample data used. 
3. Sampie Application 
a. Sample Data 
Data used for this sample application of <«he 
control concept was provided by IBM Federal Systems Space 
Shuttle Program [{ 116]. The craw manning data 1s provided in 
Appendix A. The remainder of this section is a step-by-step 
example of the ccomputicnal algorithm which implements the 


control concept of the proposed acdel. 
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eS 4 33 Sie tine 
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d =p i 
Project Curve Parameters | Maintenence Support Level 
(1) Macro technique 
cae 2 5 5 i t. = 4,33 
d 1p 
K = 1343 i re = 207 manyears 
(4.33) 
a = .08 | c = 5.1 years 
in 
: =e Zi ' = 137 manyears 
is maxX | (>. 1) ! 
<<. |  # @@=@=@=&« ~ | (2) Micro technique 
MSB = maintenance Support | ; 
boundary yY = component manning 
c 


Boundary level established 
from analysis of macre and 
micro estimations. 


Figure 4.5. 
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(cefer to Appendix A) 
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Plotted Sample Data 
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D. CoOmputaticnal Algoritha 

See ls Fit “he acemal budget data <o a Ray=- 
leigh curve. Figure 4.5 shows plotted data for the Space 
Ses l> progran. 

Sie op 2. Determine maintenance support boundary 
imecsaeoy Calculating the inflection points of both the pro- 
ject profile and maintenance phase curve. 

Sep 3. Determine support level requirements 
using micro-estimating techniques. 

Step 4. Compare values obtained from macro and 
micro methods. Analyze the differences from an economic 
Standpoint based cn management policy. 

Step 5. Predict outyear budget requirements for 
Maintenance/new develcpment contingent on management policy. 

Cc. Management Applications 

Althcugh the results shown here relate to only 
one set of data, they are encouraging in the support they 
give the model. The model presented in this thesis could 
provide a direct means to evaluate the impact of current and 
future management practices on the life-cycle ccst of tne 


sortware ystem. The idea of the development of a mainte- 


" 


nance strategy coupled with the use cf the computational 


OZ 








algorithm provides the project manager with some powerful 
Management tools. While additional research is warranted, 
it is purported that application of the model will prove 
anlighting in the fciliowing respects. 

(1) Determining Maintenance Suppert Level. 
Preliminary estimates obtained from inflection point predic- 
sors may be used as a starting point for planning workforce 
requirements to be drawn from internal assets. Likewise, if 
external or contracted support must be procured, evaluations 
of submitted bid proposals will be necessary. Although yet 
unproven statistically for accuracy, the inflection point 
predictors appear to define maximum (t ) and minimum (t ) 

ip im 

boundaries for maintenance levels. 

In accordance with the type of maintenance 
strategy chosen, a maintenance level boundary can be select- 
di. For example, if a Category IV policy is selected, man- 
power needs would approach the minimum boundary. On the 
other hand, a Category I policy would require resources ap- 
proximated by she maxinun level. With these boundaries to 
serve as guidelines, contract proposals can be viewed nore 


CmiciGally. 
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(2) Forecasting Resource Distribution. Whether 
an internal or external werkforce is used, planning and 
budgeting estimates of manloading are usually projected for 
discrete timeframes. During the maintenance phase of a via- 
ble project, «he workforce in tarms of total number remaias 
stable; however, the work distribution or functional roles 
of personnel may change (i.e. Programmers may shirtt from 
Maintenance work to development work). Within governmental 
agencies, this stability may be attributed to fixed contract 
levels or established manning levels, neither of which can 
be easily changed. Therefore, the management problem be- 
comes one consisting not only of how many personnel are 
needed, but also how can assets best be utilized. 

in Pwente cE the Eact that the users have 
changing requirements, the issue of workforce allocations 
for néw research and development must be considered. Based 
on the Rayleigh curve characteristics for a specific project 
and using a fixed support levei énvircnment, approximate 
values for workicad distribution can be calculated. 

By method of integration, the proportion of 
the total support level force that will be dedicated to pure 


Maintenance and/cr new development in future timeframes can 
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be calcalated. Figure 4.6 illustrates this point using the 


Sample data. 


MY 





aes aad 203577 -- bg $b 2 


c e 
d di 


2 -at 
i MSB - 2Kate at 


ct 


tt 


16 ~at i 
Zo7t | - 1343e 
{5 5 


101 MY (resources available for new development) 

iWete Vs 

MSB = maintenance support boundary. In this example, the 
boundary is estapdlished at the precject profilé inflec- 


tion point. Alternately, the boundary would be estabd- 
lished to indicate the manning level of the mainte- 


mance workforce. 
Figure 4.6. Forecasting Future Requirements 


Maintenance information gained with this 


‘wo 


Oversight method is twofold. The separation of development 


work (enhancements, additions, new design) from maintenance 
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work (debugging, design error correction) is accomplished, 
mreewy allowing for -Eetter interpretation of the project 
investment. The comparison of the relative proportion of 
maintenance manning versus development manning for reviewing 
project viability can also be made. This concept wiil be 
discussed rore £Fully in the next section. 

(3) Monitoring Configuration Control. A pauci- 
ty of available data prevents the comparison of actual and 
predicted manpower that is required during the maintenance 
phase. The assumpticn that the maintenance tail is flat or 
reaches a steady state seemingly arose from this lack of in- 
formation. It is the authors’ contention that new releases 
of a software product may, in fact, cause increases in the 
Maintenance tail cver time. 


Lehman and Beliady's [117, 118] research, 


discussed in chapter 3, gives strong indications that subse- 


(D 


quent releases for a software product increase complexity 


and the amount cf antigressive (maintenance) work that is 
Beqrces £Or the @etal system. BWo inherent characteristics 
of the software product directly affected by a new release 


are the system configuration and the size of the systen 


problem space. From a preject profile view, the time period 
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when these new releases occur is during the maintenance 
phasé¢. With the assertion that the work allocated to the 
completion of a new release must be considered as a phase 
within the project life-cycle, the increasé in maintenance 
costs can be explained. 

As the diagram in figure 4.7 indicates, the 
changes induced ry the release phase will cause the level of 
maintenance to increase. Unless carefully monitored, each 
new release may cause an increase in the maintenance re- 
quirements until the original maximum maintenance support 
level is reached or exceeded. When this occurs, management 
is forced to make a cost-benefit assessment of the software 
system. 

Using the concepts introduced earlier (in- 
Biec=*on DCime predicters and resource «dastribuezon fore- 
casting), maintenance saturation of the software system can 
bemedetececed. The Support line obtained from the inflection 
point predictar (t ) serves as a guideline for total system 

1p 
saturation. Management policy sets forth limits for corres- 
ponding maintenance and/cr development expenditures which 
astablishs a budget saturation level. These saturation 


levels may be equal or different. In an attempt to preclude 
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NORMALIZED PROJECT PRCFILE 
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Figure 4.7. New Release Effect on Maintenance Level 
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axcesSive maintenance costs, the saturation level viewed as 
dominant is used to trigger management's attenticn toward a 
System rebuild. For the subsequent rebuilt system, a new 
Rayleigh curve is plotted and a new cycle of pianning and 


contol begins. 


Soe eta on SUMMARY 

Pr2asented in this chapter is a bilevel model for manag- 
ing software maintenance costs. The modél, compcsed of both 
a planning concept and a control concept, suggests that the 
creation of a management strategy will have far-reaching ef- 
fects in the system total life-cycle ccsts. Used concur- 
cently, the two model concepts allow fcr smoother transla- 
son —of Mainténance objectives between the strategic 


Olremmang Level ard the operational control level. 
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V. SUMMARY, CONCLUSIONS, AND RECOMMENDATIONS 


Presented in this chapter is a summary of the thesis, 


general conclusions, and recommendations for further study. 


As SUMMARY 

Various methcdologies and system factors relating to 
software cost accounting have been reviewed in an attempt to 
develop a cost mcdet fcr the prediction of pure maintenance 
eysts. The distinction between development costs and 
Maintenance costs is considered necessary in order to pre- 
S2nt a realistic picture of the annual expenditures within a 
given budget constraint. Without a refined separation of 
these «wo cost entities, budget control is a more difficult 
task. 

Beginning with a broad background of what maintenance is 
and is not, Chapter One uncovers the paradox that exists in 
obtaining a consensus for a common working definition of 
Maintenance. Different schools of thought within the mili- 
tary and civilian research fields have produced inconsisent 
results when citing the proportion of the the life-cycle 
eeetseeet ert bputablie to total system ccsts. This inconsis- 


+ency may be due, in part, to the range of cost types (new 





development, pure maintenance, other administrative support 
activities, etc.) that exist during the maintenance panase. 
While some researchers may view each cost type individually, 
others consider the maintenance costs to be an aggregate of 
all expenditures during the maintenance phase. 

In Chapter Two, an overview of the extrinsic and intrin- 
sic charactistics of a software system which create the 
maintenance setting is prcevided. It is apparent from the 
detailed discussion of the more salient concepts that the 
maintenance issue is not cnly complicated, but also still 
somewhat elusive. While these concepts have been useful in 
explaining system characteristics and predicting future be- 
havior, they fail to produce a means for direct translation 
£0 a@ monetary value. 

Although no cost estimation technigue adaptable for man- 
agement use has keen developed sclely fcr predicting mainte- 
nance costs, application of software cost estimating schemes 

ciginally intended to evaluate the development phase have 
been extended tc inciude the maintenance phase. Chapter 
Three is devoted to a review of varicus models that have 
been suggested as appropriate for addressing the maintenance 
cost uncertainties. The models two avenues for approaching 


the issue: 





yd a System conceft using the Norden-Rayleigh curve, 
an 


2) a ees system philosophy using software evolution 
analysis. 


Current unavailability of a basic method for adequately 
determining miantenance expenditures and the increasing con- 
cern of DOD for the exorbitant funding required to sustain 
software system creraticns inspired the authors to develop a 
flexibl= management model. Chapter Four elucidates a plan- 
ning and ccentrol model which can provide project managers 
With additional information to assist in budget planning and 
decision making. This model proffers four maintenance stra- 
tegies which may be used in conjuction with calculated nmaxi- 
Mum and minimum méintenance level support boundaries specif- 


ieee the project profile. 


PeeeeenGLUSION 
While an abundance of research in scftware economics and 
software engineering exists, very little has been done that 
relates to the maintenance phase of the software life-cycle. 
As a result, there is an obvious lack of raw data available 
to analyze the proposed model for validity and sensitivity. 
With additional research, it is pelieved that the nodel 


presented inthis thesis wiil provide a direct neans to 








evaluate the impact of current and future managemen+ prac- 
tices on the life-cycle costs of software systems. The con- 
bined use of the simple macroestimating and microestimating 
+echnigques allows the manager +o look at the maintenance 
problem from different perspectives while increasing the 
confidence in the projected maintenance costs. Additional- 
ly, the computation of minimum and maximum levels of effort 
for a specific project leads to further diminution of the 
problem when management has established a particular mainte- 


mance Strategy. 


C. RECOMMENDATICKNS 
It 1s recommended that additional work within DOD be un- 
dertaken to further the research objectives of software 


maintenance costs and that this work include the following 


imade: 700 Chee ss candardudef ination that will distinguish 
between maintenance costs and costs incurred in the 
maintenance life-cycle phase; 


Peeiocrcutton of longitudinal research by software sup- 
port facilities to collect maintenance data to be used 
in the development of management tools with improved 
eacabp lity; 


3) investigaticn of the usage of additional prediction 
EeemsecO OPtain asmore complete vicw of the domain of 
software behavior during the maintenance phase; and 


Wmciainysis Of CRApirical data toO preve or disprove the 
folicwing statement: The more over-oudget and behind 
schedule that a project is delivered, the higher shouid 
a the prediction of errors detected in the Raintenance 
phasé. 
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Contained in the Wrollowing text is a partial siua- 


mary of a microestimating technique (Matrix Estimation 


Process) oktained from IBM Federal Systems Division, 


Houston, Texas. 


MATRIX METHOD 


Definition: The Matrix Method is a systematic procedure 


which can be used to delineate elements 


software project and nap them against associat- 


ed ccest elements to arrive at a project esti- 


mate. 
Things that can Lte accomplished: 
Oo Lay out project elements 
Oo Stepwise refine the elements 
Oo Estimate the elements 
°o Subtotal the estimates by grouping 
the elements 
° Total up the group estimates 


9 Refine cotal estimate 








Use Q 


Irn 
Met 


he Matrix Method 


Determine functional elements of project. 


Quantify Malntenance needs based on : 


Level = Function Size / ((Productivity) (Complexity) 


(racg<o ©) - 


Consider critical skills, operations support, and man- 
agemen*+ and support. 
Summarize for project. 


Plot with Rayleigh curve. 








Lay out a tacle cf functional areas of codé, require- 
ments areas, test areas, or functions to be performed. 
Using the fcllowing fornulas, calculate the level re- 


quired to maintain each functional area or function: 


Applications Level (FW Size)/((154) (2) (12) (2)) 


FCOS Level = (FW Size)/((100) (2) (12) (2)) 
SDL Level = (Kebine Size)/((15) (2)) 
Computer resource = (FEID Hrs Wk)/ (28) 


(Number Test Cases)/((30) (2)) 
(Number Test Cases)/((5) (2) 
(Number Test Cases)/((20) (2) 
(Number Test Cases)/((5) (2) 


GNEC Verfl. Level 
SSW Verif. Level 

SM/PL Verif. Level 
Perf. Verif. Level 


Wiese Ot hers: 
Level 
TSO Level 


(Development or Support Level) /(2) 


Reguested support level per site 
Look at critical skiils to see if eéach functional area 
is adequately covered. 


Estimate error rate and rate of change to see if level 


should be altered. 
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Harnt. CPN & 
Area Size Level Support M&S Total 
AASD 272918 FW 42.0 220 10.0 64.0 
CON/QA I 5.0 nie lia) 65.0 
Steourer  --=--- 11.0 --- --- 11.0 
ASW © T2407 TC oe) 5.0 1545 104.0 
140.5 tu 26.9 13520 


x Matrix Summary represents decomposition of the Space Shut- 


tlie Program inte major functional areas. 








AASD Matrix Estimate Summary * 


Boae Maint. OPN & 

ence aoe pee eres «EES Teta 
SM 54880 6.7 S20 1.3 11.0 
vCo 57145 5.2 —— 8 6.0 
GNEC Pog 8 16.7 4.0 2.8 23.5 
ae) 10.4 5.0 2.6 18.0 
P.A. 30975 3.0 === sD 35.5 
AASD ae. ae a EO) 250 
M&S 

Totals a Z918 42.0 12.0 10.0 64.0 


*Note: This table illustrates an additional decomposition 


of a majcr functional area into subcomponents. 


irs 








Plotted Sample Dat 
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